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REMARKS 

Claims 1-29 are pending in the application. 
Claims 1-29 have been rejected. 

Reconsideration of the Claims is respectfully requested. 
1. Rejection under Section 103 

Claims 1-29 were rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Patent No. 7,042,891, to Oberman et al. ("Oberman") in view of U.S. Patent No. 
5,274,768 to Traw et al. ("Traw"). 

Oberman was cited as "disclosing] dynamic selection of lowest latency path in a 
network switch (see Oberman col. 2 lines 29-58) . . . ." (Office Action at pp. 2-3). But, 
for example, the cluster link memory of Oberman, does not recite updating an input 
virtual channel linked list corresponding to the input virtual channel to include the data 
block. 

Oberman recites to "reduce latency when the switch is not congested, the switching 
logic may be configured to perform a cut-though operation by routing packets directly 
from input ports to output ports without storing any portion of the packet in memory." 
(Oberman 3:10-16, Abstract). 

In a congested mode, Oberman recites that "as soon as the switch becomes even 
slightly congested, then port interface 704A and switch fabric 140 will switch to store- 
and-forward routing instead of cut-through routing." (Oberman 17:1 1-14). 

With respect to memory, Oberman recites that "[c]luster link memory 404 may be 
configured as a linked list memory to store incoming packets. Packet free queue 406 is 
configured to operate as a 'free list' to specify which memory locations are available for 
storing newly received packets. In some embodiments, input block 400 may be 
configured to allocate storage within shared memory 440 using clusters." (Oberman 
7:31-35). 
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Clusters, as recited by Oberman, are "used to reduce the number of bits required for 
tracking and managing packets. Advantageously, by dividing packets into clusters instead 
of cells, the overhead for each packet may potentially be reduced. For example, in one 
embodiment shared memory 440 may allocate memory in 128-byte clusters." (Oberman 
7:42-46). 

Applicant respectfully submits that Oberman does not recite updating an input virtual 
channel linked list corresponding to the input virtual channel to include the data block. 
Also, Oberman does not recite storing the data block in a receiver buffer of the host 
device, wherein storing the data block in the receiver buffer includes storing the data 
block in the receiver buffer at an old free linked list head address. Oberman does not 
recite transfer of data blocks from an input virtual channel linked list, which includes 
reading the data block from the receiver buffer at an old input virtual channel linked list 
head address. Further, Oberman does not a receiver buffer operable to instantiate an 
input virtual channel linked list for storing data blocks on an input virtual channel basis 
and to instantiate a free list that identifies free data locations." 

Instead, Oberman recites the use of linked list of pointers to facilitate the 
manageability of a data packet during times when an output port does not have enough 
resources to cut-through by directly forwarding the bytes received at the input port to the 
output port, (see Oberman 3:10-13, Abstract). 

The Office Action notes that Oberman "does not explicitly teach updating an input 
virtual channel linked list corresponding to the input virtual channel to include the data 
block . . . ." (Office Action at p. 3). 

The Office Action cites Traw as "in the same or similar field of endeavor teaches 
updating an input virtual channel linked list corresponding to the input virtual channel to 
include the data block; storing the data block in the receiver buffer includes storing the 
data block in the receiver buffer at an old free linked list head address (columns 5-6, lines 

65-1 1 )." (Office Action at pp. 4; see also Office Action at pp. 5, 6, 10, 15, 19, 23, 

29, 33). 
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Applicant respectfully submits that Traw does not recite data routing within a host 
device, but instead provides a SONET interface to receive ATM cell data for a 
predestined device (such as "an IBM RS/6000 Workstation 4"). (see Traw Fig. 1). 

Figure 2 of Traw is recited as "a block diagram of the Reassembler 3 of the computer 
network . . . :" 



REWSE HBLED CELLS 



51S-3C 
—14 



rig . 2 



(Traw 4:58-59). The Reassembler 3, of the host interface 1, is recited as including a 
"Block 14 [that receives ATM cells from an ATM switch 7 and] splits the [ATM] cells' 
headers from the . . . cell bodies and passes the [Virtual Channel Identifiers (VCIs)] to the 
Linked List Manager 10 and the cell bodies to the Dual Port Reassembly Buffer 12. The 
Linked List Manager 10 creates a linked list for each VCI that identifies the locations in 
the Dual Port Reassembly Buffer 12 of all cell bodies associated with that VCI." (Traw 
5:54-61). 
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The linked list manager 10 "effect[s] reassembly [of the ATM cells]: 




(Traw 5:65). The interface device of Traw does not recite data routing as set out in 
Applicant's claims - Traw recites a SONET interface that receives an ATM packet, 
which splits the ATM cells' headers from the cell bodies and passes the Virtual Channel 
Identifiers (VCIs) to the Linked List Manager 10 for delivery to the IBM RS/6000 
Workstation 4, and not to a destination within a host device. 

In the hypothetical combination the Office Action submits that "[k]nown work in one 
field of endeavor may prompt variations of it for use in either the same field or a different 
one based on design incentives or other market forces/market place incentives if the 
variations are predictable to one of ordinary skill in the art." (Office Action at pp. 5, 10, 
18,22, 27,31,35). 

For a rejection based upon a "field of endeavor" rationale, "Office personnel must 
resolve the Graham factual inquiries. Then, Office personnel must articulate the 
following: (1) a finding that the scope and content of the prior art, whether in the same 
field of endeavor as that of the applicant's invention or a different field of endeavor, 
included a similar or analogous device (method, or product); (2) a finding that there were 
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design incentives or market forces which would have prompted adaptation of the known 
device (method, or product); (3) a finding that the differences between the claimed 
invention and the prior art were encompassed in known variations or in a principle known 
in the prior art; (4) a finding that one of ordinary skill in the art, in view of the identified 
design incentives or other market forces, could have implemented the claimed variation 
of the prior art, and the claimed variation would have been predictable to one of ordinary 
skill in the art; and (5) whatever additional findings based on the Graham factual 
inquiries may be necessary, in view of the facts of the case under consideration, to 
explain a conclusion of obviousness. The rationale to support a conclusion that the 
claimed invention would have been obvious is that design incentives or other market 
forces could have prompted one of ordinary skill in the art to vary the prior art in a 
predictable manner to result in the claimed invention. If any of these findings cannot be 
made, then this rationale cannot be used to support a conclusion that the claim would 
have been obvious to one of ordinary skill in the art." MPEP 2143 at page 2100-136 
(Rev. 6, Sept. 2007). 

Applicant respectfully submits that such findings have not been presented, and 
respectfully requests such findings be presented. 

Further, Applicant respectfully submits that the hypothetical combination of the 
cluster memory device of Oberman with the dissimilar ATM cell interface device of 
Traw is not based on predictable design incentives or other market forces/market place 
incentives that would achieve the invention as set out in Applicant's claims. 

For example, Traw recites that a "goal of the present invention is to provide an 
interface between a network element and a telecommunications network that operates at 
near Gbps speeds and that is compatible for use with the ATM transmission technique. . . 
. A yet further goal ... is to provide a high-performance interface for an IBM/6000 
workstation host in an ATM telecommunications network." (Traw 3:48-62). Applicant 
respectfully submits that the VCI link list serves to group related cell bodies to the 
IBM/6000 workstation host, (see Traw 6:56-64). 
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In contrast to the hypothetical combination of Oberman with Traw, Applicant's 
Independent Claim 1 recites, inter alia, a "method for routing data within a host device 
comprising: receiving a data block at a receiver of the host device . . . storing the data 
block in a receiver buffer of the host device, wherein storing the data block in the 
receiver buffer includes storing the data block in the receiver buffer at an old free linked 
list head address; . . . updating an input virtual channel linked list corresponding to the 
input virtual channel to include the data block; determining an output virtual channel for 
the data block; transferring the data block from the input virtual channel linked list of the 
receiver buffer to a destination within the host device via the output virtual channel, 
wherein transferring the data block from the input virtual channel linked list of the 
receiver buffer to a destination within the host device via the output virtual channel 
includes reading the data block from the receiver buffer at an old input virtual channel 
linked list head address; and updating the input virtual channel linked list to remove the 
data block." (emphasis added). 

Also, Applicant's Independent Claim 1 1 recites, inter alia, a "method for routing data 
within a host device comprising: . . . storing the data block in a receiver buffer of the host 
device, wherein storing the data block in the receiver buffer includes storing the data 
block in the receiver buffer at an old free linked list head address; when the input virtual 
channel has identified therewith an output virtual channel updating an output virtual 
channel linked list corresponding to the output virtual channel to include the data block; 
and when the input virtual channel has not identified therewith an output virtual channel: 
updating an input virtual channel linked list corresponding to the input virtual channel to 
include the data block; processing the data block to determine an output virtual channel 
for the data block; updating an output virtual channel linked list corresponding to the 
output virtual channel to include the data block; and updating the input virtual channel 
linked list to remove the data block." (emphasis added). 

Further, Applicant's Claim 20 recites, inter alia, a "received data processing and 
storage system comprising: ... a routing module that determines an output virtual 
channel for data blocks based upon their respective input virtual channels; a receiver 
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buffer operable to instantiate an input virtual channel linked list for storing data blocks on 
an input virtual channel basis and to instantiate a free list that identifies free data 
locations; a linked list control module operably coupled to the receiver buffer; input 
virtual channel linked list registers operably coupled to the linked list control module; 
and free linked list registers operably coupled to the linked list control module." 
(emphasis added). 

In view of the above, Applicant respectfully submits that a prima facie showing has 
not been made. 

There is not suggestion or motivation for the hypothetical combination of the cluster 
memory device of Oberman with the dissimilar ATM cell interface device of Traw. 
Further, the necessary findings to provide a "field of endeavor" determination between 
the dissimilar references has not been presented. 

Also, the cited references of the cluster memory device of Oberman and the ATM cell 
interface device of Traw do not teach or suggest all of Applicant's claim limitations. For 
example, these cited references do not refer to transferring data blocks from an input 
virtual channel linked list of a receiver buffer to a destination within the host device via 
an output virtual channel. 

2. Conclusion 

As a result of the foregoing, the Applicant respectfully submits that claims 1-29 in the 
Application are in condition for allowance, and respectfully requests allowance of such 
Claims. 

If any issues arise, the Applicant respectfully invites the Examiner to contact the 
undersigned at the telephone number indicated below or at ksmith@texaspatents.com. 
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The Commissioner is hereby authorized to charge any additional fees connected with 
this communication or credit any overpayment to Garlick Harrison & Markison Deposit 
Account No. 50-2126. 

Respectfully submitted, 

Date: September 11, 2009 /Kevin L. Smith/ 

Kevin L. Smith, Reg. No. 38,620 
Attorney for Applicant 

Garlick Harrison & Markison 

P.O. Box 160727 
Austin, Texas 78716-0727 
(972) 772-8836/office 
(972) 772-5033/facsimile 
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